Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md`:
- Around line 65-102: Two Tier A artifacts referenced in the
component-to-artifact-to-evidence map are missing from the repository:
tla/SentinelContainmentProtocol.tla and tla/KillSwitchAbstract.tla. These files
are cited as having verifiable TLC model-checking evidence (75 + 13 states with
no errors) for the containment one-way ratchet and kill-switch abstraction
control components. Either create and add these TLA+ files to the repository
with the corresponding TLC verification results, or update the table rows
referencing these files to remove them and correct the Tier A evidence claims to
match what actually exists in the repository.
- Around line 397-412: The "Full assurance suite" row in the verification ledger
section claims "11/11 PASS" but the actual execution of bash
governance_artifacts/run_runnable_assurance.sh fails at the OPA policy tests
step because OPA is not installed. Update the "Last result" column for the "Full
assurance suite" row to reflect the actual failure output (e.g., "FAIL: opa:
command not found" or similar), or alternatively ensure all required
dependencies including OPA, TLC, terraform, node, and python3 packages are
properly installed and available in the environment so the command can execute
successfully and produce the claimed result. Verify that all other commands in
the verification ledger table also execute correctly and produce their claimed
outputs before updating their results.

---

Nitpick comments:
In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md`:
- Around line 65-83: The ASCII architecture diagram code block starting at line
65 does not have a language identifier in its opening fence. Add a language
identifier such as `text` or `ascii` immediately after the opening triple
backticks (e.g., change the opening fence from ``` to ```text) to improve
markdown linting compliance and readability of the diagram block.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py`:
- Line 28: The os module is imported at the top of the
run_pilot_acceptance_gates.py file but is never used anywhere in the script.
Remove the import os statement to clean up unused imports and improve code
clarity.

In `@governance_blueprint/roadmap_2026_2035.yaml`:
- Around line 70-117: The validator function `validate_roadmap_2035_shape()` in
governance_blueprint/validation/validate_artifacts.py accumulates validation
errors throughout its execution but fails to return them, instead returning None
implicitly. Add a `return errors` statement at the end of the function after
line 299 to ensure that accumulated validation errors are properly propagated to
the caller and validation failures are correctly reported instead of silently
passing.

---

Nitpick comments:
In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py`:
- Around line 107-118: In the check_containment_tlc() function, the return code
variable rc is unpacked from the _run() call but never used since the function
only checks the output text for error messages. Replace rc with an underscore
(_) in the tuple unpacking statement to indicate the value is intentionally
ignored and follows Python convention for unused variables.

In `@next-app/app/api/consent/route.ts`:
- Line 36: The ts property assignment in the consent route includes a redundant
type cast `as unknown as string` after calling `new Date().toISOString()`. Since
the toISOString() method already returns a string type, the explicit cast is
unnecessary and should be removed. Simply replace the line to use `ts: new
Date().toISOString()` without any type annotations.

In `@next-app/app/api/intent/route.ts`:
- Around line 18-21: The message validation in the intent route only checks for
type but not for empty strings, whereas the chat route validates for empty
strings using message.length === 0. Add an additional validation check after the
typeof validation for the message variable to reject empty strings and return a
400 response with an appropriate error message, ensuring consistency with the
chat route's validation behavior.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/runnable-assurance.yml:
- Around line 101-118: The dashboard-tests job has two security issues that need
to be fixed. First, pin the actions/checkout and actions/setup-node action
references to specific commit hashes instead of the mutable version tags (v4) to
eliminate supply chain risk. Second, add persist-credentials: false to the
checkout step to prevent credential persistence and potential exposure of
repository credentials. These changes address the static analysis findings for
governance-critical workflows by removing mutable action references and
disabling unnecessary credential persistence.
- Around line 72-76: The hashicorp/setup-terraform action is referenced using a
mutable version tag (`@v3`) instead of an immutable commit hash, which introduces
supply chain security risk. Replace the `@v3` reference in the Set up Terraform
(for pilot IaC gate) step with a specific commit SHA to pin the action to an
immutable version. This ensures that the workflow always uses the exact same
code and prevents unexpected changes or potential compromises to the action.

In `@governance_artifacts/pilot/run_pilot_acceptance_gates.py`:
- Around line 229-237: The issue is that when the --json flag is provided, the
code outputs machine-readable JSON but then continues to print human-readable
banner text and report output, which breaks JSON parsing. To fix this, after
processing and outputting JSON data (which occurs around lines 248-277), check
the args.json flag and immediately return or exit if JSON mode is enabled,
preventing the banner text printed at lines 233-237 and any subsequent
human-readable output from being printed in the same run.

In `@governance_blueprint/DECADAL_STRATEGIC_TECHNICAL_PLAN_2026_2035.md`:
- Around line 276-277: The security review status in the React dashboards
section at line 276 is outdated and conflicts with the PR's actual results.
Update the check count from "5/5" to "14/14" to reflect the passing dashboard
security tests achieved by this PR's hardening efforts. Additionally, update
lines 399-400 to indicate that DASH findings have been remediated and are no
longer open, rather than implying they remain outstanding. Ensure all language
describing the dashboard security status is consistent with the PR's stated
remediations and current test results.

In `@next-app/app/api/auth/login/route.ts`:
- Around line 15-25: The POST function in route.ts accepts client-provided roles
without validation, allowing privilege escalation where a user could request
privileged roles like "dpo". Instead of simply filtering roles by type,
implement an allowlist of explicitly permitted roles that users can assign to
themselves. Only include roles from the client request that match this
allowlist, and reject or ignore any attempts to assign privileged or sensitive
roles. This prevents the authorization bypass where clients can mint tokens with
elevated permissions.

In `@next-app/lib/http/rateLimit.ts`:
- Around line 48-51: The clientKey function is using the first value from the
x-forwarded-for header as the rate limiting key, which is spoofable and allows
clients to rotate arbitrary keys to evade throttling. To fix this, modify the
logic to use a more trusted client IP source, such as taking the last value from
the x-forwarded-for header split (since the rightmost value is added by the most
recent proxy and is harder to spoof) instead of the first value, or prioritize a
more trusted header source. Ensure the rate limiter keys are derived from a
source that cannot be easily manipulated by end users.

In `@next-app/lib/privacy/consentLedger.ts`:
- Around line 49-50: The userId is used directly in path construction without
sanitization in the chainFile assignment, creating a path traversal
vulnerability where values like `../` could escape DATA_DIR. Sanitize the userId
parameter before using it in the path.join call by validating it contains only
safe characters or using path.basename to extract just the filename component.
Apply this same sanitization fix at both locations where this pattern appears
(the chainFile assignment and the other location at line 76-77).
- Around line 79-85: The current verification logic using
events.every(verifyEvent) only validates individual event signatures but does
not verify chain linkage. You need to enhance the verification to ensure that
each event's prevHash field matches the hash of the previous event in the
sequence, creating a continuous cryptographic chain. Modify the verification
logic to iterate through the events array and check that consecutive events are
properly linked together, in addition to the existing per-event signature
verification via verifyEvent.

In `@next-app/middleware.ts`:
- Around line 12-16: The RateLimiter instance created at module level
accumulates expired client keys without any cleanup mechanism, causing unbounded
memory growth. Implement a periodic cleanup routine by calling a sweep or
cleanup method on the limiter instance (likely a method like sweep() or
cleanup() on the RateLimiter class) at regular intervals using setInterval to
remove expired entries from the rate limiter's internal bucket storage.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@governance_artifacts/oscal/oscal_conformance.py`:
- Around line 96-101: The _iso_duration_ok helper currently lets degenerate ISO
duration segments like PT or P inside a periodic/retest pair pass because it
only special-cases the whole value and then checks the split parts with
_ISO_DUR. Update _iso_duration_ok so each segment in the split value is
validated as a non-empty, non-degenerate duration, not just matched against
_ISO_DUR; use the existing _ISO_DUR and the _iso_duration_ok function to reject
empty or bare-P/bare-PT parts in both single and paired forms.

In `@governance_artifacts/run_runnable_assurance.sh`:
- Around line 129-134: Step 12 in run_runnable_assurance.sh only verifies the
Python command’s exit status and then uses grep just for reporting, unlike the
earlier validation steps that also assert on the expected message. Update the
OSCAL conformance check around the oscal_conformance.py invocation so it also
guards on the presence of the “OSCAL conformance:” output line before calling
pass, matching the pattern used in Steps 5–7 and keeping the check consistent
with the rest of the script.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/runnable-assurance.yml:
- Line 106: The workflow step using actions/upload-artifact is pinned to a
mutable tag, so update the runnable-assurance workflow to reference
actions/upload-artifact by an immutable commit SHA instead of v4. Locate the
upload step in the workflow and replace the current uses value with the specific
SHA for the same major version so the action reference cannot change
unexpectedly.

In `@governance_artifacts/oscal/generate_annex_iv_dossier.py`:
- Around line 179-185: The build_dossier flow currently loads catalog bodies via
_load_catalogs before checking OSCAL validity, so a malformed catalog can fail
early instead of using the validator report path. Update build_dossier to call
_run_conformance before _load_catalogs, then only hydrate catalogs/controls
after conformance passes; keep the existing control-loading logic and use the
build_dossier and _run_conformance symbols to locate the change.

In `@governance_artifacts/run_runnable_assurance.sh`:
- Around line 137-149: Step 13 is only checking dossier shape because
run_runnable_assurance.sh invokes generate_annex_iv_dossier.py with --no-verify,
so build_dossier() never exercises backing checks or live SATISFIED evidence.
Update this step to run the generator through the verified path and assert the
evidence/status fields from the resulting dossier, or if that is not intended,
adjust the step’s assertion/message and related RUNNABLE_ASSURANCE wording to
claim only assembly structure. Use the generate_annex_iv_dossier.py invocation
and the d["dossier"] assertions as the place to align the test with the
documented live-evidence behavior.